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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by the Special Mobile Group (SMG). 

The present document defines the stage 2 Functional description of Location Services (LCS) within the digital cellular 
telecommunications system (Phase 2/Phase 2+). 

The contents of the present document are subject to continuing work within SMG and T1P1 and may change following 
formal SMG and T1P1 approval. Should SMG or T1P1 modify the contents of the present document it will then be 
re-issued with an identifying change of release date and an increase in version number as follows: 

Version 7.x.y 

where: 

7 GSM Phase 2+ Release 1998; 

x the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc.; 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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1 Scope 

The present document defines the stage-2 service description for the LoCation Services (LCS) feature on GSM, which 
provides the mechanisms to support mobile location services of operators, which are not covered by standardized GSM 
services. CCITT 1.130 [4] describes a three-stage method for characterization of telecommunication services, and 
CCITT Q.65 [5]defines stage 2 of the method. 

The LCS feature is a network feature and not a supplementary service. This version of the stage 2 service description 
covers aspects of LCS e.g., the functional model, architecture, positioning methods, message flows etc. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

• For this Release 1998 document, references to GSM documents are for Release 1998 versions (version 7.x.y). 

[1] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 

acronyms". 

[2] GSM 02.71: "Digital cellular telecommunications system (Phase 2+); Location Services (LCS); 

Service description; Stage 1". 

[3] GSM 03.07: "Digital cellular telecommunications system (Phase 2+); Restoration Procedures" 

[4] CCITT Recommendations 1. 130: "General modelling methods - Method for the characterisation of 

telecommunication services supported by an ISDN and network capabilities of an ISDN". 

[56] CCITT Recommendation Q.65: "Methodology - Stage 2 of the method for the characterization of 

services supported by an ISDN". 



3 Definitions, abbreviations and symbols 
3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

Location Estimate: the geographic location of an MS and/or a valid ME, expressed in latitude and longitude data. The 
Location Estimate shall be represented in a well-defined universal format. Translation from this universal format to 
another geographic location system may be supported, although the details are considered outside the scope of the 
primitive services. 

Mobile Originating Location Request (MO-LR): any location request from a client MS to the LCS Server made over 
the GSM air interface. While an MO-LR could be used to request the location of another MS, its primary purpose is to 
obtain an estimate of the client MS's own location. 

Mobile Terminating Location Request (MT-LR): any location request from an LCS client where the client is treated 
as being external to the PLMN to which the location request is made. 
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Network Induced Location Request (NI-LR): any location request for a target MS from a client that can be 
considered to lie inside any of the PLMN entities currently serving the target MS. In this case, the LCS client is also 
within the LCS server. Examples of an NI-LR include a location request needed for supplementary services, for 
emergency call origination and by O&M in a visited PLMN. 

North American Emergency Services Routing Digits (NA-ESRD): a telephone number in the North American 
Numbering Plan (NANP) that can be used to identify a North American emergency services provider and any associated 
LCS client. The ESRD shall also identify the base station , cell site or sector from which a North American emergency 
call originates. 

North American Emergency Services Routing Key (NA-ESRK): a telephone number in the North American 
Numbering Plan (NANP) assigned to an emergency services call by a North American VPLMN for the duration of the 
call that can be used to identify (e.g. route to) both the emergency services provider and the switch in the VPLMN 
currently serving the emergency caller. During the lifetime of an emergency services call, the ESRK can also be used to 
identify the calling mobile subscriber. 

3.2 Abbreviations 

Abbreviations used in the present document are listed in GSM 0104. 



For the purposes of the present document, the following abbreviations apply: 



LIR 


Location Immediate Request 


LDR 


Location Deferred Request 


LCF 


Location Client Function 


LCCF 


Location Client Control Function 


LCAF 


Location Client Authorization Function 


LMMF 


LMU Mobility Management Function 


LMU 


Location Measurement Unit 


LSCF 


Location System Control Function 


LSAF 


Location Subscriber Authorization Function 


LSPF 


Location Subscriber Privacy Function 


LSBF 


Location System Billing Function 


LSOF 


Location System Operations Function 


LCCTF 


Location Client Coordinate Transformation Function 


MO-LR 


Mobile Originating Location Request 


MT-LR 


Mobile Terminating Location Request 


NI-LR 


Network Induced Location Request 


MLC 


Mobile Location Center 


PRCF 


Positioning Radio Coordination Function 


PCF 


Positioning Calculation Function 


PSMF 


Positioning Signal Measurement Function 


SLPP 


Subscriber LCS Privacy Profile 


TA 


Timing Advance (between an MS and its serving BTS) 


TOA 


Time of Arrival 



3.3 Symbols 

For the purposes of the present document, the following symbols apply: 

Le Interface between External User and MLC (external interface) 

Lh Interface between Gateway MLC and HLR (HLR interface) 

Lg Interface between Gateway MLC and VMSC (gateway MLC interface) 

Ls Interface between Serving MLC and VMSC (serving MLC interface) 

Lv Interface between Serving MLC and VLR (VLR interface) 

Um Air Interface to an LMU (measurement interface) 
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4 Main concepts 

LCS utilizes one or more positioning mechanisms in order to determine the location of a Mobile Station. Positioning a 
target MS involves two main steps: signal measurements and location estimate computation based on the measured 
signals. 

Three positioning mechanisms are proposed for LCS: Uplink Time of Arrival (TO A), Enhanced Observed Time 
Difference (E-OTD), and Global Positioning System (GPS) assisted. TOA is described in this document. E-OTD and 
assisted-GPS will be described in LCS phase 2. 

Note: Due to regional regulatory mandates, TOA will be standardized for LCS first. Further work on E-OTD and GPS 
will continue after TOA is completed. At that time, descriptions of E-OTD and GPS will be moved into the main 
document. 

4.1 Timing Advance (TA) 

The TA is based on the existing Timing Advance (TA) parameter. The TA value is known for the serving BTS. To 
obtain TA values in case the MS is in idle mode a special call, not noticed by the GSM subscriber (no ringing tone), is 
set up. The cell-ID of the serving cell and the TA is returned as the result of the TA. 

TA is used to assist all positioning mechanisms and as a fall-back procedure. 

4.2 Time of Arrival (TOA) positioning mechanism 

The TOA positioning mechanism is based on collecting time of arrival (TOA) measurements computed from access 
bursts generated by the mobile. These bursts are generated by having the mobile perform an asynchronous intracell 
handover. Access bursts are received and measured by serving and neighboring base stations. 

This method requires additional hardware at the listening BTSs to accurately measure the TOA of the bursts. 



5 General LCS architecture 

5.1 LCS access interfaces and reference points 

There is one reference point between the LCS PLMN server and LCS client called Le. Le is described in GSM 02.71 
however the protocol specifics are for further study. There may be more than a single LCS network interface to several 
different LCS clients or other networks. These networks may both differ in ownership as well as in communications 
protocol. The network operator should define and negotiate interconnect with each external LCS client or other network. 

An interface differs from a reference point in that an interface is defined where specific LCS information is exchanges 
and needs to be fully recognized. 

There is an inter-LCS PLMN interface called Lg that connects two independent LCS networks for message exchange. 
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Figure 1 : LCS Access Interfaces and Reference Points 



5.2 LCS Functional diagram 

GSM 02.71 [2] describes the overall LCS service description from the LCS client point of view. In the present 
document, a more detailed description of LCS is given. The LCS functional diagram shown in Figure 2 depicts the 
interaction of the LCS client and the LCS server within the PLMN. The PLMN uses the various LCS components within 
LCS server to provide the target MS Location Information to the LCS client. 
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LCS Client 



Client handling component 



IX F, 




IX I: 


IX I 3 




IX In 



▲ 



Location Service Request Location Service Response 

▼ : 




LCS Server 



Figure 2: PLMN LCS capability server Functional Diagram 

5.3 LCS CLIENT 

An LCS client contains an LCS component with one or more client(s) which by using location information can provide 
location based services. 

An LCS client is a logical functional entity that requests from the LCS server in the PLMN location information for one 
or more than one target MS within a specified set of parameters such as Quality of Service (QoS). The LCS Client may 
reside in an entity (including the MS) within the PLMN or in an entity external to the PLMN. The specification of the 
LCS Client's internal logic and its relation to the external use is outside the scope of this document. 
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5.3.1 LCS Component 

5.3.1 .1 Location Client Function (LCF) 

The Location Client Function (LCF) provides a logical interface between the LCS client and the LCS server. This 
function is responsible for requesting location information for one or more MEs/MSs with a specified "QoS" and 
receiving a response, which contains either location information or a failure indicator. 

5.4 LCS Server 

5.4.1 Client handling component 

5.4.1 .1 Location Client Control Function (LCCF) 

The Location Client Control Function (LCCF) manages the external interface towards LCF. The LCCF identifies the 
LCS client within the GSM PLMN by requesting client verification and authorization ( i.e. verifies that the LCS client is 
allowed to position the subscriber) through interaction with the Location Client Authorization Function (LCAF). The 
LCCF handles mobility management for location services (LCS), e.g.: forwarding of positioning requests to VMSC. The 
LCCF determines if the final positioning estimate satisfies the QoS for the purpose of retry/reject. The LCCF provides 
flow control of positioning requests between simultaneous positioning requests. It may order the Location Client 
Coordinate Transformation Function (LCCTF) to perform a transformation to local coordinates. It also generates 
charging and billing related data for LCS via the Location System Billing Function (LSBF). 

5.4.1.2 Location Client Authorization Function (LCAF) 

The Location Client Authorization Function (LCAF) is responsible for providing access and subscription authorization 
to a client. Specifically, it provides authorization to a LCS client requesting access to the network and authorizes the 
subscription of a client. LCAF provides authorization to a LCS client requesting Location Information of a specific MS. 

5.4.1.2.1 Access Subfunction 

An Access Subfunction enables LCS clients to access LCS services. This subfunction provides verification and 
authorization of the requesting client. 

When a LCS is requested, the Access Subfunction uses the information stored in the LCS client subscription profile to 
verify that: 

the LCS client is registered; and 

the LCS client is authorized to use the specified LCS request type; 

the LCS client is allowed to request location information for the subscriber(s) specified in the LCS request; 

5.4.1.2.2 Subscription Subfunction 

The LCS client Subscription profile shall contain a minimum set of parameters assigned on per LCS client basis for an 
agreed contractual period. The LCS client profile shall contain the following set of access parameters: 

LCS client identity; 

Allowed LCS request types (i.e. LIR, LDR or both); 

Maximum number of subscribers allowed in a single LCS request; 

Priority; 

Position override indicator; 
State(s); 
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Event(s) (applicable to LDR requests only ); 

Local coordinate system; 

LCS client access barring list (optional); 

PLMN access barring list applicability. 

For certain authorized LCS client internal to the PLMN, a subscription profile is unnecessary. These clients are 
empowered to access any defined service that is not barred for an MS subscriber. This permits positioning of emergency 
calls without the need for pre-subscription. 

5.4.2 System handling component 

5.4.2.1 LMU Mobility Management Function (LMMF) 

The LMU Mobility Management Function (LMMF) is responsible for maintaining the operational status of LMUs and 
registering each LMU in an SMLC. Operation of the LMMF is independent of other logical LCS functions and its 
output is provided to the PRCF. 

5.4.2.2 Location System Control Function (LSCF) 

The Location System Control Function (LSCF) is responsible for coordinating location requests. This function manages 
call-related and non-call-related positioning requests of GSM LCS and allocates network resources for handling them. 
The LSCF retrieves MS classmark for the purpose of determining a positioning method. The LSCF performs call setup 
if required as part of a LCS e.g., putting the ME in a dedicated mode and obtains Cell-ID. It also caters for coordinating 
resources and activities with regard to requests related to providing assistance data needed for positioning. This function 
interfaces with the LCCF, LSPF, LSBF and PRCF. Using these interfaces, it conveys positioning requests to the PRCF, 
relays positioning data to the LCCF and passes charging related data to the LSBF. 

5.4.2.3 Location System Billing Function (LSBF) 

The Location System Billing Function (LSBF) is responsible for charging and billing activity within the network related 
to location services (LCS). This includes charging and billing of both clients and subscribers. Specifically, it collects 
charging related data and data for accounting between PLMNs. 

5.4.2.4 Location Client Coordinate Transformation Function (LCCTF) 

The Location Client Coordinate Transformation Function (LCCTF) provides conversion of a location estimate 
expressed according to a universal latitude and longitude system into an estimate expressed according to a local 
geographic system understood by the LCF and known as location information. The local system required for a particular 
LCF will be either known from subscription information or explicitly indicated by the LCF. 

5.4.2.5 Location System Operations Function (LSOF) 

The Location System Operations Function (LSOF) is responsible for provisioning of data, positioning capabilities, data 
related to clients and subscription (LCS client data and MS data), validation, fault management and performance 
management of GSM LCS. 

5.4.3 Subscriber Component 

5.4.3.1 Location Subscriber Authorization Function (LSAF) 

The Location Subscriber Authorization Function (LSAF) is responsible for authorizing the provision of a location 
service (LCS) for a particular mobile. Specifically, this function validates that a GSM LCS can be applied to a given 
subscriber. The LSAF verifies the client MS's subscription. 
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5.4.3.2 Location Subscriber Privacy Function (LSPF) 

The Location Subscriber Privacy function is responsible performs all privacy related authorizations. For an target MS it 
shall authorize the positioning request versus the privacy options of the target MS, if any. 

5.4.4 Positioning component 

5.4.4.1 Positioning Radio Coordination Function (PRCF) 

The Positioning Radio Control Function (PRCF) manages the positioning of a mobile through overall coordination and 
scheduling of resources to perform positioning measurements. This function interfaces with the PSMF and PCF. The 
PRCF determines the positioning method to be used based on the QoS, the capabiities of the network, and the MS's 
location capabilities. It determines which PSMFs to be involved or what to measure, and obtains processed signal 
measurements from PSMF. Next, it packs the signal measurement data from the PSMF into a certain format and 
forwards it to the PCF. 

5.4.4.2 Positioning Calculation Function (PCF) 

The Positioning Calculation Function (PCF) is responsible for calculating the position of the mobile. It obtains BTS 
related data e.g., BTS geographic co-ordinates and stores this data. This function applies an algorithmic computation on 
the collected signal measurements to compute the final location estimate and accuracy. It also supports conversion of 
mobile's location estimate between different geodatic reference systems. 

5.4.4.3 Positioning Signal Measurement Function (PSMF) 

The Positioning Signal Measurement Function (PSMF) is responsible for gathering uplink or downlink radio signal 
measurements for calculation of a mobile's position. These measurements can be positioning related or ancillary. 



Other types of national specific information flows may be supported in addition to the information flow specified here. 

Any of the information flows here indicated may not be externally realized if the information does not flow over an open 
interface. On the other hand, if a flow goes over an open interface, it shall abide to a well-defined protocol, which will 
be further specified in other relevant specifications. 



Via the Location Service Request, the LCS client communicates with the LCS server to request for the location 
information of one or more than one MS within a specified quality of service. There exist two types of location service 
requests: 

Location Immediate Request (LIR); and 
Location Deferred Request (LDR). 
The following attributes are identified for Location Service Request information flow: 
Target MS; 
LCS identity; 
State (idle, dedicated); 
Event (applicable to LDR requests only); 
Quality of Service information; 



5.5 



Information Flows between Client and Server 



5.5.1 



Location Service Request 
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Local coordinate system; 
Geographical area. 

5.5.2 Location Service Response 

The Location Service Response is sent to the LCS client as the result of the Location Service Request by the LCS 
Server: 

Immediate Response; and 

Deferred Response; 

These deferred responses can be either single or periodic. 

Logical architecture 

LCS is logically implemented on the GSM structure through the addition of one network node, the Mobile Location 
Center (MLC). It is necessary to name a number of new interfaces. A generic LCS logical architecture is shown below in 
Figure 3. LCS generic architecture can be combined to produce LCS architecture variants. No inference should be 
drawn about the physical configuration on an interface from Figure 3. 
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Figure 3: Generic LCS Logical Architecture 

5.5.3 BSS 

The BSS is involved in the handling of various positioning procedures. As a generic handling procedure, the BSS 
provides Cell-id and TA to the VMSC. Specific BSS functionality is specified in each of the positioning procedures 
section. 



LCS Client 

The LCS client is outside the scope of this standard. 
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GMLC 

The Gateway Mobile Location Center (GMLC) contains functionality required to support LCS. In one PLMN, there 
may be more than one GMLC. 

The GMLC is the first node an external LCS client accesses in a GSM PLMN (i.e. the Le reference point is supported 
by the GMLC). The GMLC may request routing information from the HLR via the Lh interface. After performing 
registration authorization, it sends positioning requests to and receives final location estimates from the VMSC via the 
Lg interface. 



5.5.4 SMLC 

The Serving Mobile Location Center (SMLC) contains functionality required to support LCS. In one PLMN, there may 
be more than one SMLC. 

The SMLC is the node that is serving the MS (i.e. the Ls interface is supported by the SMLC to the MSC). The SMLC 
manages the overall coordination and scheduling of resources required to perform positioning of a mobile. It also 
calculates the final location estimate and accuracy. 

The SMLC controls a number of LMUs for the purpose of obtaining radio interface measurements to locate or help 
locate MS subscribers in the area that it serves. The SMLC is administered with the capabilities and types of 
measurement produced by each of its LMUs. Signaling between an SMLC and LMU is transferred via the MSC serving 
the LMU using the Ls and Um interfaces. The following measurements returned by an LMU to an SMLC have a generic 
status in being usable for more than one position method (e.g. including TOA): 

(a) Radio interface timing information. 

The SMLC and GMLC functionality may be combined in the same physical node, combined in existing physical nodes, 
or reside in different nodes. The SMLC and GMLC are not interconnected. They are connected through the VMSC. 
When the VMSC and GMLC are in different PLMNs, they are interconnected via the Lg interface. 



MS 

The MS may be involved in the various positioning procedures. Specific MS involvement is specified in each of the 
positioning procedures section. 



LMU 

An LMU makes radio measurements to support one or more positioning methods. These measurements fall into one of 
two categories: 

Location measurements specific to one MS used to compute the location of this MS; 

Assistance measurements specific to all MSs in a certain geographic area. 

All location and assistance measurements obtained by an LMU are supplied to a particular SMLC associated with the 
LMU. Instructions concerning the timing, the nature and any periodicity of these measurements are either provided by 
the SMLC or are pre-administered in the LMU. All signaling to an LMU is exclusively over the GSM air interface (Um 
Interface): there is no wired connection to any other network element. An LMU thus has a serving BTS, BSC, MSC and 
VLR in addition to an SMLC and interacts with the first four of these like a normal GSM MS. In particular, an LMU has 
its own IMSI and subscription profile in a home HLR and supports all radio resource and mobility management 
functions of the GSM air interface that are necessary components to the LMU procedures defined here. 

NOTE: A network operator may assign specific ranges of IMSI for its LMUs and may assign certain digits within 
the IMSI to indicate the associated SMLC. Certain digits in the IMSI may also be used as a local identifier 
for an LMU within an SMLC. 
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To ensure that the LMU and its associated SMLC can always access one another, an LMU may be homed (camped) on a 
particular location area (or location areas) belonging to one MSC. For real LMUs, the HLR contains a special profile 
indicating no supplementary services, except possibly SMS-PP MT (for data download via the SIM application toolkit), 
and barring of all incoming and possibly outgoing calls. An identifier in the HLR profile also distinguishes an LMU 
from a normal MS. All other data specific to an LMU is administered in the LMU and in its associated SMLC. 

The following assistance measurements obtained by an LMU have a generic status in being usable by more than one 
position method: 

Radio Interface Timing measurements - comprise Absolute Time Differences (ATDs) or Real Time Differences (RTDs) 
of the signals transmitted by Base Stations, where timing differences are measured relative to either some absolute time 
reference (ATD) or the signals of another Base Station (RTD). 



The MSC contains functionality responsible for MS subscription authorization and managing call-related and non-call 
related positioning requests of GSM LCS. The MSC is accessible to the GMLC via the Lg interface and the SMLC via 
the Ls interface. 



The VLR is responsible for registering an LMU in its associated SMLC after the LMU has performed a successful 
location update. The VLR also deregisters any LMU that has been purged or cancelled in the VLR. Signaling to support 
registration and deregistration is transferred via the Lv interface between the VLR and SMLC. 



The HLR contains LCS subscription data and routing information. The HLR is accessible from the GMLC via the Lh 
interface. For roaming MSs, HLR may be in a different PLMN that the current SMLC. 



5.6 Assignment of functions to general logical architecture 



MSC 



5.5.5 



VLR 



HLR 



Table 1 maps LCS functions into network elements. 
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Table 1 : Mapping of LCS Functions into Network Elements 
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6 General Network Location Procedures 



6.1 State Description for the GMLC 
6.1.1 GMLC States 

6.1.1.1 NULL State 

In the NULL state, a particular location request from some LCS client either has not been received yet or has already 
been completed. After a location request is received from a LCS client, the GMLC remains in the NULL state while the 
identity of the client and nature of its location request are verified. . While the NULL state exists conceptually, it need 
not be represented explicitly in the GMLC. 

6.1 .1 .2 INTERROGATION State 

In this state, the GMLC has sent an interrogation to the home HLR of the MS to be located and is awaiting a response 
giving the VMSC address and IMSI for this MS. 

6.1.1.3 LOCATION State 

In this state, the GMLC has sent a location request to the VMSC serving the MS to be located and is awaiting a response 
containing a location estimate. 
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6.1.2 State Functionality 



6.1.2.1 



State Transitions 




Figure 4: State Transitions in the GMLC 



Moving from NULL to INTERROGATION state: 

If the GMLC does not know the VMSC address or MS IMSI when it receives a location service request from some LCS 
client, it moves from the NULL state to the INTERROGATION state and sends a request to the MS's home HLR for the 
VMSC address and IMSI. 

Moving from NULL to LOCATION state: 

If the GMLC already knows both the VMSC address and MS IMSI when it receives a location service request from 
some LCS client (e.g. from information retained for an earlier location request for the same MS), it moves from the 
NULL state to the LOCATION state and sends a location request to the VMSC. 

Moving from INTERROGATION to LOCATION state: 

After the GMLC, in the INTERROGATION state, receives the VMSC address and IMSI from the home HLR, it enters 
the LOCATION state and sends a location request to the VMSC of the MS being located. 

Moving from LOCATION to NULL state: 

After the GMLC receives a location estimate response from the VMSC, it forwards the location estimate to the 
requesting LCS client and reenters the NULL state. 



The GMLC runs a timer while in the INTERROGATION state to limit the amount of time waiting for an interrogation 
response from the HLR. If the timer expires before an interrogation response is received, the GMLC indicates a location 
failure to the LCS client and reenters the NULL state. 



The GMLC runs a timer while in the LOCATION state to limit the amount of time waiting for a location estimate 
response from the VMSC. If the timer expires before a response is received, the GMLC indicates a location failure to 
the LCS client and reenters the NULL state. 



6.1.2.2 



INTERROGATION Timer Function 



6.1.2.3 



LOCATION Timer Function 
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6.2 State Description for the VMSC 
6.2.1 VMSC States 

6.2.1.1 IDLE State 

In this state, the VMSC location service is inactive for a particular MS. The MS may be known in the VLR (except for a 
SIMless Emergency call or where the MS record has been canceled or lost in the VLR), but there may not be an active 
Mobility Management or Radio Resource connection to the MS. 

6.2.1.2 LOCATION State 

In this state, the VMSC is awaiting a response from the SMLC after requesting the location for a particular MS. In this 
state, a Radio Resource connection, a Mobility Management connection and the LCS layer of the Connection 
Management connection to the MS will be active - allowing the SMLC and MS to exchange positioning related 
messages for mobile based and mobile assisted position methods. For certain position methods (e.g. network based 
position methods), the SMLC may invoke substates in the VMSC during which other types of association are maintained 
with the MS (e.g. temporary call establishment). Such substates are defined in later sections for each positioning 
method. In this state, the VMSC may also transfer positioning related messages between the SMLC and those LMUs 
served by the VMSC. 

6.2.1.3 State Functionality 

6.2.1 .4 State Transitions 




Messages 



Figure 5: State Transitions in the VMSC 

Moving from IDLE to LOCATION state: 

After a request has been received to locate a particular MS and the MS subscription options have been verified, a 
location request is sent to the SMLC associated with the serving cell of the MS to be located: the VMSC then enters the 
LOCATION state. Before entering this state, the VMSC must have obtained the current cell ID and TA value for the 
MS and setup a Radio Resource, a Mobility Management and a Connection Management connection to the MS if none 
was previously active. 

Moving from LOCATION to IDLE state: 

After the return of a location estimate result from the SMLC, the VMSC shall reenter IDLE state. 
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6.2.1 .5 LOCATION Timer Function 

The VMSC runs a timer while in the LOCATION state to limit the amount of time waiting for a location response from 
the SMLC. If the timer expires before such information is received, the VMSC indicates a location failure to the original 
requesting entity and reenters IDLE state. 

6.3 State Description for the SMLC 

6.3.1 SMLC States 

6.3.1.1 NULL State 

This is a conceptual rather than actual state in which a certain location request from a particular VMSC either has not 
yet been received or has been completed. 

6.3.1.2 LOCATION State 

This state exists after the SMLC has received a location request from a VMSC and persists while the SMLC is obtaining 
position measurements for a particular positioning method until such time as positioning measurements have been 
received and a location estimate has been computed and returned to the VMSC. 

When sufficient positioning measurement results have been received, the SMLC either evaluates them, if they include an 
already computed location estimate, or uses them to compute a location estimate. The SMLC then has the option of 
either reinitiating another positioning attempt, if the location estimate did not satisfy the required QoS, or returning the 
location estimate to the VMSC. 

6.3.2 State Functionality 
6.3.2.1 State Transitions 




Return 
Location 
results to the 
VMSC or 
Timeout 



via the 
VMSC 

Figure 6: State Transitions in the SMLC 
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Moving from NULL to LOCATION state: 

After a location request is received from the VMSC, the SMLC chooses a positioning method and initiates the 
appropriate position measurements. It then enters the LOCATION state. 

Moving from LOCATION to NULL state: 

When the SMLC has obtained a location estimate that best meets the requested QoS parameters, it returns this to the 
VMSC and reenters the NULL state. 

6.3.2.2 LOCATION Timer Function 

The SMLC runs a timer while in the LOCATION state to limit the total amount of time that positioning can be active. 
This timer should be related to any response time indicated in the location request QoS parameters. If the timer expires 
before a final location estimate has been produced, the SMLC either returns the best existing location estimate to the 
VMSC (e.g. an estimate based on the current cell ID) or returns a failure indication. It then reenters the NULL state. 

6.4 General Network Positioning Procedures 

The generic network positioning procedure of providing the location information of an MS subscriber can be partitioned 
into the following procedures: 

Location Preparation Procedure 

This generic procedure is concerned with verifying the privacy restrictions of the MS subscriber, reserving network 
resources, communicating with the MS to be located and determining the positioning method to be used for locating the 
MS subscriber based on the requested QoS and the MS and network capabilities. 

Positioning Measurement Establishment Procedure 

This procedure is concerned with performing measurements by involving the necessary network and/or MS resources. 
Depending on the positioning method to be used for locating the MS the internals of this procedure can be positioning 
method dependent. The procedure is completed with the end of the positioning measurements. 

Location Calculation and Release Procedure 

This generic procedure is initiated after the measurements are completed and is concerned with calculating the location 
of the MS and releasing all network and/or MS resources involved in the positioning. 

6.4.1 Mobile Terminating Location Request (MT-LR) 

Figure 7 illustrates general network positioning for LCS clients external to the PLMN. In this scenario, it is assumed that 
the target MS is identified using either an MSISDN or IMSI. 
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Figure 7: General Network Positioning for a MT-LR 



6.4.1.1 Location Preparation Procedure 

An external LCS client requests the current location of a target MS from a GMLC. The GMLC verifies the identity of 
the LCS client and its subscription to the LCS service requested and derives the MSISDN or IMSI of the target MS to 
be located and the LCS QoS from either subscription data or data supplied by the LCS client. For a call related location 
request, the GMLC obtains and authenticates the called party number of the LCS client (refer to Annex A for further 
details). If location is required for more than one MS, or if periodic location is requested, steps 2 to 12 below may be 
repeated. 

If the GMLC already knows both the VMSC location and IMSI for the particular MSISDN (e.g. from a previous 
location request), this step and step 3 may be skipped. Otherwise, the GMLC sends a 

MAP_SEND_ROUTING_INFO_FOR_LCS message to the home HLR of the target MS to be located with either the 
IMSI or MSISDN of this MS. 



The HLR verifies that the SCCP calling party address of the GMLC, corresponds to a known GSM network element that 
is authorized to request MS location information. The HLR then returns the current VMSC address and whichever of the 
IMSI and MSISDN was not provided in step (2) for the particular MS. 

The GMLC sends a MAP_PROVIDE_SUBSCRIBER_LOCATION message to the VMSC indicated by the HLR. This 
message carries the MS subscriber's IMSI, LCS QoS information (e.g. accuracy, response time, preferred/required 
positioning method) and an indication of whether the LCS client has the override capability. For a call related location 
request, the message also carries the LCS client's called party number. The message may optionally carry the identity of 
the LCS client. 
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If the GMLC is located in another PLMN or another country, the VMSC first authenticates that a location request is 
allowed from this PLMN or from this country. If not, an error response is returned. If the target MS has an established 
circuit call other than speech, the location request is denied and an error response is returned to the GMLC. Otherwise, 
the VMSC then verifies LCS barring restrictions in the MS user's subscription profile in the VLR. If LCS is barred and a 
LCS client accessing a GMLC in the same country does not have the override capability, an error response is returned to 
the GMLC. Otherwise, if the MS is in idle mode, the VLR performs paging, authentication and ciphering. This 
procedure will provide the MS user's current cell ID and certain location information that includes the TA value in the 
BSSMAP Complete layer 3 Information used to convey the Paging Response. If the MS is instead in dedicated mode, 
the VMSC will have been supplied with the current cell ID from either the serving BSC or serving MSC in the case of 
an established call with MSC-MSC handover. 

The VMSC sends a MAP_PERFORM_LOCATION message to the SMLC associated with the MS's current cell 
location. This message includes the MS's location capabilities and currently assigned radio channel type (SDCCH, 
TCH-FR or TCH-HR), the requested QoS and the current Cell ID and, if available, any location information including 
the TA value received in step 5. 

6.4.1.2 Positioning Measurement Establishment Procedure 

If the requested location accuracy within the QoS can be satisfied by the reported cell ID and, if available, TA value, the 
SMLC may send a MAP_PERFORM_LOCATION ack. immediately. Otherwise, the SMLC determines the positioning 
method and instigates the particular message sequence for this method defined in subsequent sections. If the position 
method returns position measurements, the SMLC uses them to compute a location estimate. If there has been a failure 
to obtain position measurements, the SMLC may use the current cell ID and, if available, TA value to derive an 
approximate location estimate. If an already computed location estimate is returned for an MS based position method, 
the SMLC may verify consistency with the current cell ID and, if available, TA value. If the location estimate so 
obtained does not satisfy the requested accuracy and sufficient response time still remains, the SMLC may instigate a 
further location attempt using the same or a different position method. 

6.4.1.3 Location Calculation and Release Procedure 

When a location estimate best satisfying the requested QoS has been obtained, the SMLC returns it to the VMSC. 

The VMSC returns the location estimate and its age to the GMLC. The VLR may then release the Mobility Management 
connection to the MS, if the MS was previously idle, and the VMSC may record billing information. 

The GMLC returns the MS location estimate to the requesting LCS client. If the LCS client requires it, the GMLC may 
first transform the universal location coordinates provided by the VMSC into some local geographic system. The GMLC 
may record billing for both the LCS client and inter-network revenue charges from the VMSC's network. 

6.4.2 MT-LR without HLR Query - applicable to North America only 

Figure 8 illustrates location for a North American Emergency Services call, where an emergency services client 
identifies the target MS using an IMSI, MSISDN or NA-ESRK plus, possibly IMEI, that were previously provided to it 
by the VMSC (e.g. see section 6.4.5). The emergency services client also identifies the VMSC to the GMLC by 
providing an NA-ESRD or NA-ESRK. This allows the GMLC to request location from the VMSC without first 
querying the home HLR of the target MS. This is necessary when the home HLR either cannot be identified (client 
provides an NA-ESRK but not IMSI or MSISDN) or does not support the LCS query procedure. 
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Figure 8: Positioning for a Emergency Services MT-LR without HLR Query 



Same as step 1 in Figure 7 but with the LCS client identifying first the target MS by an IMSI, MSISDN or NA-ESRK 
and possibly IMEI and, second, the VMSC by an NA-ESRK or NA-ESRD. 

The GMLC determines the VMSC using the NA-ESRK or NA-ESRD. The 

MAP_PROVIDE_SUBSCRIBER_LOCATION message sent to the VMSC carries the IMSI, MSISDN or NA-ESRK 
and, if provided, the IMEI for the target MS, as well as the required QoS and an override indication. The VMSC 
identifies the target MS using the IMSI, MSISDN or NA-ESRK and, if provided, the IMEI. 

To (7) Same as steps 6 to 10 in Figure 7. 



6.4.3 MT-LR for a previously obtained location estimate 

Every time the location estimate of a target MS subscriber is returned by the SMLC to the VMSC, the VMSC may store 
the location estimate together with a time stamp in the subscriber's VLR record. 

The time stamp is the time at which the location estimate is stored at the VLR i.e. after the SMLC returns the location 
estimate to the VMSC. The time stamp indicates the 'age' of the location estimate. 



6.4.3.1 Initial Location 

In the context of an originating emergency call the location estimate and the associated time stamp at the 
commencement of the call set-up is referred to as 'initial location '. 



6.4.3.2 Current Location 

After a location attempt has succesfully delivered a location estimate and its assocoiated time stamp, the location 
estimate and time stamp is referred to as the 'current location' at that point in time. 



6.4.3.3 Last known Location 

The current location estimate and its associated time stamp are stored in MSC/VLR and until replaced by a later location 
estimate and a new time stamp is referred to as the 'last known location '. 

Figure 9 illustrates location where the VMSC does not invoke positioning but returns either a location estimate or a 
failure indication. This scenario is valid for the following types of location request. 
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Some time after an emergency services call has started, an emergency services client requests the initial location of the 
target MS at the start of the emergency call. (If the emergency call has just started, the VMSC may follow the procedure 
in Figure 7 to obtain the initial location). 

A LCS client requests location with a "no delay" response time. 
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Figure 9: MT-LR for a previously obtained location estimate 



Same as step 1 in Figure 7, but with the LCS client requesting either the initial location for an emergency call or location 
with a "no delay" response time. 

Same as step 2 in Figure 7. If the VMSC is identified using a NA-ESRK or NA-ESRD, then this step and step 3 are not 
needed. 

Same as step 3 in Figure 7. 

Same as step 4 in Figure 7. The message sent to the VMSC requests either an initial location or location with "no delay". 

If the initial location for an emergency call is requested and the VMSC has previously obtained and stored this, this 
location estimate and its age are returned to the GMLC. Otherwise, if the initial location is not stored and this is not the 
start of the emergency call, a failure indication is returned. If location is requested with "no delay", the last known 
location currently stored in the VMSC and its age are returned; if no location is stored, a failure indication is returned. 

Same as step 10 in Figure 7. 



6.4.3.4 Security and Privacy 

The handling of security and privacy of the target MS with regard to returning the location estimate of the target MS 
shall be the same as when the target MS is reachable for positioning, (i.e. the requesting LCS client is authorized and the 
privacy of the target MS is secured before the VMSC check the VLR status of the target MS (i.e. whether the MS is 
marked as attached or detached in the VLR). 



6.4.3.5 Failing to locate the target MS 

In case of a 'Detached' or 'Not Reachable' target MS, the last known location and a time stamp stored at the VLR, may 
be returned to a LCS client requesting location information. 

Note: Due to CAMEL, the MSC/VLR may already be storing other location information parameters like location 
number, cell id, location area identity and VLR number in the subscriber's VLR record. 

When a request for location information is received at the VMSC, the requested QoS shall indicate whether the 'last 
known location of the target MS' should be returned in case of a 'detached' or 'not reachable' target MS. 

If the VLR has a valid copy of the subscriber's permanent data and the target MS's privacy settings are such that 
positioning is allowed, then the following two cases can occur. 
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6.4.3.5.1 Target MS is 'Not Reachable' 

If the target MS is marked as 'attached' in the VLR, the VMSC orders paging of the target MS. If paging fails, due to 
target MS being 'not reachable' then VMSC shall check whether the LCS client has requested 'last known location' in 
case of 'not reachable' target MS. 

If such a request exists, the VMSC shall include the last known location together with the time stamp available in its 
response to the request for location information. 

An indicator of 'last known location' returned shall be marked at the CDR at VMSC. 

6.4.3.5.2 Target MS is 'Detached' 

If the target MS is marked as 'detached' in the VLR, the VMSC shall check whether the LCS client has requested 'last 
known location' in case of 'detached' target MS. 

If such a request exists, the VMSC includes the 'last known location' together with the time stamp available in its 
response to the request for location information. 

An indicator of 'last known location' returned shall be marked at the CDR at VMSC. 

6.4.3.5.3 Target MS is 'Purged' 

If the target MS is marked as 'Purged' in HLR, then an indication Absent Subscriber' is returned to the GMLC. 

6.4.4 Network Induced Location Request (NI-LR) 

Figure 10 illustrates positioning for an emergency service call. 
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Figure 10: Positioning for a NI-LR Emergency Service Call 
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6.4.4.1 Location Preparation Procedure 

An initially idle MS requests an SDCCH and sends a DTAP CM Service Request indicating a request for an Emergency 
Service call to the VMSC via the BSC. 

The BSC includes the current cell ID and certain location information that includes the TA value within the BSSMAP 
Complete Layer 3 Information message used to convey the CM service request across the A-interface. The MS may 
identify itself using a TMSI, IMSI or IMEI. 

The VMSC, BSC and MS continue the normal procedure for emergency call origination towards the appropriate 
emergency services client. Depending on local regulatory requirements, the sending of call setup information into the 
PSTN may be delayed until either the MS's location has been obtained or the location attempt has failed or a PLMN 
defined timer has expired before location was obtained. Call setup information sent into the PSTN may include the MS 
location (if already obtained) plus information that will enable the emergency service provider to request MS location at 
a later time. 

At any time after step 1, the VMSC may initiate procedures to obtain the MS's location. These procedures may run 
either in parallel with the emergency call origination or while emergency call origination is suspended to delay sending 
of call setup information into the PSTN according to step 3. The VMSC sends a MAP_PERFORM_LOCATION 
message to the SMLC associated with the MS's current location area. This message includes the MS's location 
capabilities and currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS required for an 
emergency call and the current Cell ID and any location information including the TA value received in step 2. 

6.4.4.2 Positioning Measurement Establishment Procedure 

The actions described under step 7 for a MT-LR are performed. If a speech compatible traffic channel is required for 
network based positioning (e.g. TO A), the same traffic channel may be used for both the positioning and the emergency 
call. In that case, the traffic channel may be allocated by either the positioning procedure or emergency call origination 
procedure. 

6.4.4.3 Location Calculation and Release Procedure 

When a location estimate best satisfying the requested QoS has been obtained, the SMLC returns it to the VMSC. 

Depending on local regulatory requirements, the VMSC may send a MAP Subscriber Location report to a GMLC 
associated with the emergency services provider to which the emergency call has been or will be sent. This message 
shall carry any location estimate returned in step 8, the age of this estimate and may carry the MSISDN, IMSI and IMEI 
of the calling MS. In North America, any NA-ESRD and any NA-ESRK that may have been assigned by the VMSC 
shall be included. The message shall also indicate the event that triggered the location report. If location failed (i.e. an 
error result was returned by the SMLC in step 8), an indication of failure rather than a location estimate may be sent to 
the GMLC. 

The GMLC acknowledges receipt of the location information. 

The GMLC may optionally forward any information received in step 7 to the emergency services LCS client. For a 
North American emergency services call this client may be selected according to the NA-ESRD provided in step 7. The 
GMLC may also store the information received in step 7 for later retrieval by the emergency services LCS client. 

Depending on local regulatory requirements, steps 4 to 9 or steps 7 to 9 may be repeated at subsequent intervals - e.g. 
after the emergency call is answered and following release. In case of any notification following release, the GMLC and 
LCS client should release any call-related information (e.g. NA-ESRK) provided earlier. 
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6.5 



Exception Procedures 



6.5.1 



Procedures in the SMLC 



When a location attempt fails due to failure of a position method itself (e.g. due to inaccurate or insufficient position 
measurements and related data) and the SMLC is unable to instigate another positioning attempt (e.g. due to a 
requirement on response time), the SMLC may return a MAP Perform Location response containing a less accurate 
location estimate (e.g. based on serving cell and timing advance). If a less accurate estimate is not available or will not 
meet the accuracy requirement, the SMLC shall instead return a MAP Perform Location Return Error message to the 
VMSC indicating the cause of failure. 

When a location attempt is interrupted by some other unrecoverable error event inside the SMLC, the SMLC shall 
immediately terminate the location attempt and return a MAP User Abort message to the VMSC containing the reason 
for the location attempt cancellation. In that case, any dialogue previously opened with an LMU or serving BSC for the 
purpose of instigating position measurements for the MS being located may also be aborted by the SMLC. 

If the SMLC receives an Abort indication from the VMSC, it shall immediately terminate the location attempt and may 
abort any dialogues used for the location attempt that still exist with any LMUs. Although the SMLC cannot abort any 
location procedure instigated in the serving BSC (e.g. for TOA), the circumstances of the abort may still ensure 
cancellation of any such procedure (see section on BSC). 

If the SMLC has instigated any network based positioning procedure in the serving BSC for the target MS (e.g. TOA) 
and receives an error indication from the serving BSC, it shall cancel the network positioning attempt and may abort any 
dialogues used for this positioning attempt that currently exist with any LMUs. The SMLC may then instigate another 
positioning method or return any location estimate already derived to the VMSC, or the SMLC may return a MAP 
Perform Location return error to the VMSC indicating failure of positioning. If the reason for the BSC error was 
commencement of a radio related handover for the target MS, the SMLC may instead wait for a MAP LCS Information 
Report from the VMSC containing an indication from the new serving BSC that the handover procedure is complete. 
This message will also provide the new serving cell ID if the handover to a new cell was successful and the new timing 
advance. The SMLC may then resume positioning of the target MS or (e.g. if the new serving cell belongs to a different 
SMLC), it may return a MAP Perform Location return error to the VMSC requesting restart of the location attempt. 



After the VMSC has requested a location estimate for a particular MS from the SMLC, certain events may occur that 
may temporarily or permanently interfere with the location attempt. For each such event notified to the VMSC, the 
VMSC shall employ one of the following error recovery actions. 

Restart the Location Attempt 

This action shall be employed for any event that temporarily impedes a location attempt and cannot be delayed until the 
location attempt is complete. When such an event is notified to the VMSC, it shall immediately cancel the location 
attempt and the associated MAP dialogue with the SMLC, if this still exists by sending a MAP User Abort message (in a 
TCAP Abort transaction) to the SMLC. The Abort message shall contain the reason for the location procedure 
cancellation. If the SMLC had previously returned a TCAP CONTINUE transaction to the VMSC within the MAP 
dialogue initiated by the VMSC, the Abort message would be conveyed immediately to the SLMC. If the SMLC had not 
returned any TCAP response to the VMSC, the Abort would not be conveyed immediately to the SMLC, although the 
TCAP dialogue with the SMLC would be terminated in the VMSC: the normal rules of TCAP then ensure that a TCAP 
provider Abort will be returned to the SMLC following the first TCAP response from the SMLC to the VMSC. 

After aborting the location request dialogue with the SMLC, the VMSC shall queue the location request until the event 
causing the restart has terminated. The VMSC may optionally wait for an additional time period (e.g. if the queuing 
delay is minimal) to ensure that any resources allocated in and by the SMLC have time to be released. If the restart was 
instigated by the SMLC, the VMSC need not wait. The VMSC shall then send another location request to the SMLC 
associated with the current serving cell of the target MS. 



6.5.2 



Procedures in the VMSC 
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Abort the Location Attempt 

This action shall be employed for any event that permanently impedes a location attempt, such as loss of the DCCH to 
the target MS. When such an event is notified to the VMSC, it shall cancel the current location attempt and the 
associated MAP dialogue with the SMLC, if still existing, by sending a MAP User Abort message (in a TCAP Abort 
transaction) to the SMLC. The Abort message shall contain the reason for the location procedure cancellation. The 
VMSC shall then return an error response to the client or network entity from which the location request was originally 
received. The VMSC shall also release all resources (e.g. DCCH) specifically allocated for the location attempt. 

The following table indicates the appropriate error recovery procedure for certain events. For events not listed in the 
table (e.g. handover), the VMSC need take no action. 



Table 2a: LCS Error Recovery Procedures in the VMSC for certain Events 



Event 


VMSC Error Recovery 


Release of radio channel to the MS 


Abort 


Any error response from the SMLC except for restart 


Abort 


Error response from the SMLC requesting restart 


Restart 



















6.5.3 Procedures in an LMU 

An LMU shall return an error indication to its controlling SMLC when location measurements previously ordered by the 
SMLC cannot be provided due to any error condition. 

6.5.4 Procedures in the BSC 

Depending on the position method and its current state of execution, a serving BSC may chose to defer certain radio 
related events (e.g. handover) to avoid interference with location - refer to the later sections for each position method. A 
serving BSC shall abort any existing location related procedure related to a particular target MS without notifying the 
SMLC if the DCCH to the target MS or the SCCP connection to the VMSC is released or if a new location procedure is 
instigated. A serving BSC shall return an error indication to the SMLC by sending a BSSMAP Location Information 
Report to the VMSC (see section 6.8) when any other event that cannot be deferred (e.g. handover) impedes the normal 
progress of a network based position method (e.g. TO A). The error indication shall indicate the nature of the event. In 
the case of intra-BSC handover or failure of handover, the serving BSC shall also notify the SMLC when the handover 
is complete (or has failed) by sending another BSSMAP Location Information Report to the VMSC. In the case of 
successful handover, this message shall also include the new serving cell ID and timing advance. In the case of inter- 
BSC or inter-MSC handover, the original serving BSC shall include an indication that network positioning has been 
interrupted in the data transferred to the new serving BSC to support handover (in the BSSMAP Handover Required 
message). In this case, the new serving BSC shall send the indication of handover completion together with the new 
serving cell ID and timing advance to the SMLC instead of the previous BSC. It shall be left up the SMLC to determine 
whether to cancel or continue with the location attempt when these indications are received. 

6.5.5 Procedures for Handover 



6.5.5.1 Inter-MSC Handover 

When a location estimate is required for a target MS with an established call in a state of inter-MSC handover, the 
serving cell ID or serving location area ID shall be used by the visited MSC to identify the correct SMLC to perform the 
location. All layer-3 BSSMAP and DTAP Location request related messages that are transferred over the A-interface 
shall now be sent via MAP/E interface piggy-backed in MAP_FORWARD_ACCESS_SIGNALLING and MAP 
PROCESS_ACCESS_SIGNALLING between the visited and serving MSCs. 
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6.5.5.2 Handling of an ongoing handover while a request for positioning arrives at 
MSC/VLR 

If during an ongoing radio handover procedure a request for location information arrives at the MSC/VLR, the request 
shall be suspended until the HANDOVER COMPLETE message is received at the MSC/VLR. On completion of the 
handover, the MSC/VLR shall issue continue with location preparation procedure. 

6.5.5.3 Handling of an ongoing LCS procedure while handover is required 

During an ongoing LCS procedure, if handover is required, LCS procedure shall be stopped until the handover is 
completed or rejected. The LCS procedure shall be initiated again after the completion or failure of the handover. The 
restart of the Location Procedure has been discussed in chapter 6.5.2. 

6.6 Privacy 

6.6.1 Privacy Override Indicator (POI) 

The POI is used to determine whether the privacy settings of the subscriber to be positioned shall be overridden by the 
request for location services. The assignment of a POI value with an 'override' or 'not override' value in the LCS client 
profile is done during the LCS client provisioning. The type of LCS client requesting location information (i.e. 
commercial, emergency, law-enforcement etc.) shall determine the value of the POI assigned to the LCS client profile. 

There are two distinct cases regarding the handling of the privacy override indicator. 

Procedure A: If the subscriber to be positioned is in the same PLMN or same country at the GMLC then the POI shall 
override the subscriber's privacy options. 

Procedure B: Otherwise the POI shall not override the subscriber's privacy options. 

6.6.2 Privacy Procedures 

The SLPP shall contain the privacy options defined in the HLR of the MS subscriber. 

The SLPP shall be downloaded to the VMSC together with the rest of his subscription information in the existing MAP 
operation INS ERT_S UB S CRIB ER_D AT A. It will be deleted with the existing MAP operation 
DELETE_S UB S CRIB ER_D AT A . 

The POI is transferred from the GMLC to the VMSC in the location request. Based on the location of the GMLC the 
VMSC evaluates whether to accept or ignore the received POI according to the definition in Section 6.6.1. 

If the POI is accepted the location requested is unconditionally performed. Otherwise if the POI is ignored the VMSC 
evaluates the privacy options in the MS subscriber's subscription profile (assuming this is held in the VLR). If the VLR 
does not contain the MS subscription profile, LCS will rely on the existing GSM recovery mechanisms to obtain the 
profile. 

If the location request is allowed by the privacy options the location request is performed. Otherwise, if the location 
request is barred by the privacy options, the location request is refused an error response is returned to the GMLC with a 
cause code indicating that the request was rejected by the subscriber. 

6.6.3 MS Privacy Options 

The MS privacy options in the SLPP apply to an MT-LR or NI-LR and either indicate that no MT-LR or NI-LR is 
allowed for the MS (except as may be overridden by the POI or local regulatory requirements) or define the particular 
classes of LCS client for which an MT-LR or NI-LR is allowed, with the following classes being possible: 

- Universal Class - allow positioning by all LCS clients; 

- Call related Class - allow positioning by any LCS client to which the MS originated a call that is currently 
established; 
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Non-Call related Class - allow positioning by specific identified LCS Clients or groups of LCS Client with the 
following restrictions allowed for each identified LCS Client or group of LCS Clients; 

- Location request allowed only from a GMLC in the HPLMN; 

- Location request allowed only from a GMLC in the home country; 

- Location request allowed from any GMLC. 

PLMN operator Class - allow positioning by specific types of client within or associated with the VPLMN, with the 
following types of client identified: 

- clients providing a location related broadcast service; 

- O&M client in the HPLMN (when the MS is currently being served by the HPLMN); 

- O&M client in the VPLMN; 

Clients recording anonymous location information without any MS identifier; 

- Clients enhancing or supporting any supplementary service, IN service, bearer service or teleservice subscribed 
to by the target MS subscriber. 

If the MS subscribes to the universal class, any MT-LR shall be allowed by the VMSC. If local regulatory requirements 
mandate it, any MT-LR for an emergency services LCS client and any NI-LR for an emergency services call origination 
shall be allowed by the VMSC. If the MS subscribes to the call-related class, an MT-LR shall be allowed if the MS 
previously originated a call that is still established and the called party number either dialed by the MS or used by the 
VMSC for routing matches the called party number received from the GMLC. If the MS subscribes to the non-call 
related class, an MT-LR shall be allowed if the identity of the LCS client or LCS client group supplied by the GMLC 
matches the identity of any LCS Client or LCS Client group contained in the MS's SLPP and any other restrictions 
associated with this LCS Client identity in the SLPP are also met. If the MS subscribes to the PLMN class, an NI-LR or 
MT-LR shall be allowed if the client within the VPLMN, for an NI-LR, or the client identified by the GMLC, for an 
MT-LR, either matches a generic type of client contained in the MS's SLPP or is otherwise authorized by local 
regulatory requirements to locate the MS. 

6.7 CM Procedures 

6.7.1 Location request for a mobile in idle-mode 

When a request for location information is received at the VMSC the LCS-layer shall order paging of the MS 
subscriber. In case of first unsuccessful paging, normal paging procedures should apply. After successful paging the 
LCS-layer shall invoke the location preparation procedure. 

6.7.2 Location request for a mobile in dedicated-mode 

When a request for location information is received at the VMSC, if the MS is already busy on CM level, the LCS-layer 
shall attempt to establish a parallel transaction to the existing one. If successful, the LCS-layer shall invoke the location 
preparation procedure. 

6.8 Common Procedures to support SMLC to BSS Signaling 
6.8.1 SMLC to BSC Information Transfer Procedure 

The SMLC to BSC Information Transfer Procedure enables location related commands, responses and control 
information to be transferred between an SMLC and the serving BSC for a target MS via the visited MSC. The 
procedures apply to network based positioning methods like TOA and TA. The procedures are only valid during the 
lifetime of the MAP transaction between the SMLC and visited MSC for the target MS that is initiated by the transfer of 
a MAP Perform Location request from the VMSC to the SMLC and terminated, normally, by the return of a MAP 
Perform Location response. 
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Figure 11 : SMLC to Serving BSC Information Transfer Procedure 

The SMLC sends a MAP LCS Information Request to the visited MSC serving a particular target MS. This message 
shall be linked to the MAP Perform Location request previously transferred from the VMSC toi SMLC. It contains 
location related information intended for the serving BSC. 

The VMSC transfers the location related information received in step 1 to the serving BSC for the target MS in a 
BSSMAP Location Command. Steps 1 and 2 may be repeated if the SMLC needs to transfer further location 
information to the serving BSC. 

Some time after receiving the location information in step 2, the BSC may return location response information to the 
SMLC by sending a BSSMAP Location Information Report to the VMSC containing this information. 

If the MAP transaction with the SMLC to perform positioning for the target MS is no longer open, the VMSC shall 
discard the message received in step 3. Otherwise, the VMSC shall transfer any location response information received 
in step 3 to the SMLC in a MAP LCS Information Report. This message shall be associated with the MAP transaction 
currently established between the VMSC and SMLC for positioning the target MS. 

6.8.2 SMLC to BSC Report Error Procedure 

The SMLC to BSC report error procedure may be optionally requested by an SMLC when attempting to transfer LCS 
Information to a particular serving BSC via the VMSC for a certain target MS. If the procedure is requested and the 
VMSC cannot transfer LCS Information to the serving BSC, an LCS error indication is returned to the SMLC together 
with the content of the original LCS Information Request sent earlier by the SMLC. 
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Figure 12: SMLC to BSC Report Error Procedure 



The SMLC sends a MAP LCS Information Request to the visited MSC serving a particular target MS. This message 
shall be linked to the MAP Perform Location request previously transferred from the VMSC toi SMLC. It contains 
location related information intended for the serving BSC and a "report error" indication. 

If the location information received in step 1 cannot be successfully transferred to the serving BSC for the target MS 
(e.g. due to errors in the received message) and provided the "report error" indication was sent in step 1, the VMSC 
returns a MAP LCS Information Report to the SMLC containing the same location information received in step 1 and 
the cause of the error. This message shall be associated with the MAP transaction currently established between the 
VMSC and SMLC for positioning the target MS. The SMLC may use the content of the location information for 
correlation with the information sent in step 1 . 
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6.9 



Common Procedures for a Circuit Mode LMU 



6.9.1 Architectural requirements 
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Figure 11 : Association between LMU(s) and SMLC(s) through various VLR(s) 



6.9.1.1 SMLC requirements 

A PLMN consists of one or more SMLC(s). There is no direct connection between SMLC(s) within a PLMN. 

An SMLC area is associated with one or more VLR areas within a PLMN. 

An SMLC area consists of location areas (LA). A LA shall be controlled by only one SMLC. 

An LMU belonging to SMLC-A shall register with SMLC-A even if the registration is done via VLR-2 due to radio 
conditions, see figure 3.1. An SMLC behaves as the 'home" for all LMU(s) belonging to that SMLC. 

An SMLC shall select the LMUs that are best suited to perform measurements for the target MS according to the serving 
cell of and other radio related information available to the SMLC. 

The LMU registration is done either by deriving the SMLC address from the LMU IS MI or by an association existing in 
the VLR between the serving cell id and its associated SMLC. 

6.9.1.2 LMU requirements 

An LMU is registered at a VLR depending on the radio conditions as described in GSM TS 03.22; 

- An LMU shall behave as an MS unless otherwise stated; 

- An LMU shall register at 'home' SMLC determined by its IMSI or at the SMLC associated with the LMU's 
current serving cell id. 
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In addition to the MM common procedures an LMU shall support the following MM specific procedures: 

- Location updating procedure; 

- Periodic updating; 

- IMSI attach procedure; 

- as specified in GSM TSs 04.08 "Mobile Radio L3 interface" and 09.02 "Mobile Application Protocol (MAP) 
specification"; 

- LMU handovers shall be supported (both intra and inter MSC); 

it shall be optional whether an LMU shall support the IMSI attach/detach procedure; 

- the MAP Cancel Location operation shall not cause de-registration of an LMU from its SMLC. 

6.9.1.3 VLR requirements 

A VLR may be associated with one or more SMLC(s). 

Based on the serving cell-id of the target MS, the VLR shall select the SMLC to send the request for positioning 
measurements. 

It is an MSC/VLR implementation option whether the VLR shall be able to derive the SMLC address of the LMU by 
using the LMU IMSI number or by using the serving cell id, which has an association to an SMLC defined in the VLR. 

If the indicator "Location Information Confirmed in SMLC" is set to "Not Confirmed" then the VLR shall order 
registration of the LMU at the SMLC at the next LMU originating transaction or SMLC terminating transaction. 

In case of an LMU begin detached (i.e. IMSI detach flag is set) the VLR shall reject all transactions towards the LMU 
being in detach state. 

6.9.1.4 HLR requirements 

It shall be able to distinguish between an MS and an LMU. 

6.9.2 LMU registration 

The registration is used to indicate to an SMLC that an LMU is available and provides the SMLC the address of the 
serving MSC/VLR. 
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Figure 12: Registration of an LMU at SMLC following location update 

The LMU shall perform location updating according to GSM TS 03.22 and 04.08 MM specific and common 
procedures. 

The SMLC shall be registered in the following cases: 

when the LMU registers in a new VLR i.e. the VLR has no data for that LMU; 

when the LMU registers in a new location area of the same VLR and the MSC area has changed; 

if the indicator "Location Information Confirmed in SMLC" is set to "Not Confirmed" because of a VLR or 
SMLC restart see TS GSM 03.07 for further details. 

On reception of the existing DTAP CM Service Request the visiting MSC derives the address of SMLC either form the 
LMU IMSI or from the serving CI of the LMU. 



Next, the location update to the HLR is performed according to procedures described in GSM TS 09.02. 
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The operation MAP Update Location initiates the MAP Insert Subscriber Data operation, which informs the VLR of any 
LMU related data. 

On successful downloading of the LMU data, the VLR shall send the acknowledgement to the HLR in MAP Insert 
Subscriber Data Ack. 

On successful location updating at the HLR, the existing message MAP Update Location Ack is returned to the VLR. 

After successfully updating the HLR, the VLR shall order registration of the LMU at the selected SMLC by sending 
with the message MAP_RegistrationRequest which includes the address of the MSC, the IMSI of the LMU and possibly 
theLMSI. 

The SMLC performs the registration of the LMU and acknowledges the operation to the VLR in the 
MAP_RegistrationRequest Ack message. In case of failure of the registration, i.e. in case no reply is sent to the VLR or 
a delayed reply to the VLR, will cause timeout at the VLR. The procedure shall be repeated at the next location update 
(IMSI attach, Periodic or Normal location update). The indicator "Location Information Confirmed in SMLC" remains 
to "Not Confirmed". 

On successful LMU registration at the selected SMLC, the VLR shall complete the location update procedure by 
sending the existing layer 3 message Location Update Accept to the LMU. 

6.9.3 LMU Deregistration 

De-registration is used to inform an SMLC that an LMU is currently unavailable. Note that de-registration does not 
necessarily imply that an LMU may have failed (e.g., de-registration may occur due to MAP Cancel Location operation) 

6.9.3.1 Purging an LMU 

This service is used between the VLR and the SMLC to cause the SMLC to mark its data for an LMU so that any 
request for performing measurements for a target MS or any other diagnostics will be treated as if the LMU is not 
reachable. It is invoked when the subscriber (LMU) record is to be deleted in the VLR, either by MMI interaction or 
automatically e.g. because the LMU has been inactive for certain period of time. 
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Figure 13: De-registration of an LMU due to purging 

Due to automatic de-registration or due to manual de-registration an LMU a command is send to HLR to purge an LMU 
in MAP_Purge_MS. 

After the LMU data is purged, the HLR acknowledges the purging in MAP Purge_MS_Ack. 

On reception of the acknowledgment from HLR, the VLR initiates de-registration of the LMU from its serving MLC 
(SMLC) by sending the new message MAP_RegistrationRequest carrying an indication of deregistration. 

The SMLC deletes the LMU from its database and sends an acknowledgement to the VLR in the message 
MAP_RegistrationRequest_Ack 



6.9.3.2 Cancel Location 

Normally, de-registration of an LMU from the SMLC shall not be done when an LMU performs a location update from 
an old VLR to a new VLR (since an LMU has a 'home' SMLC). 

In some cases a cancel location operation may be used by operator determined purposes to delete the subscriber's 
(LMU) record from the network. In that case, the VLR shall instigate the de-registration procedure to delete the 
registration of an LMU at the SMLC. 

The HLR shall indicate in the cancellation type (cancellation type = subscription withdrawn) that the cancel location 
operation is initiated e.g. by the operator to withdraw the subscription of the LMU. Depending on the cancellation type 
the VLR shall determine whether de-registration of an LMU to the SMLC, following a cancel operation, shall be done 
or not. 
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4. MAP Cancel Location 



Figure 14: De-registration due to Cancel Location operation 

The steps below assume that the cancellation type indicates cancellation type = subscription withdrawn. 

The HLR orders in MAP_Cancel_Location a VLR to cancel the LMU data due to the LMU's registration in a new VLR 
area. 

If the cancel operation is related to an LMU and the cancellation type indicates "subscription withdrawn", the VLR 
orders de-registration in the message MAP_RegistrationRequest. The registration type in this message indicates 
deregistration. 

After the LMU subscription is withdrawn, the SMLC acknowledges the withdrawal in MAP_RegistrationRequest_Ack. 

On reception of the acknowledgment from SMLC, the VLR sets the indicator "Location Information Confirmed in 
SMLC" to "Not Confirmed" and then acknowledges the cancel location operation to the HLR in the existing message 
MAP_Cancel_Location_Ack. 



6.9.4 LMU-SMLC Information Transfer Procedure 

The LMU-SMLC information transfer procedure is a generic procedure applicable to all circuit mode LMUs. It allows 
an SMLC to either invoke or terminate particular types of location measurement or O&M activities in the LMU and 
allows the LMU to return location measurement or O&M results. If an LMU is pre-administered with all necessary data 
regarding the required location measurements or O&M activities, a measurement or O&M command from the SMLC 
would not be mandatory. Because the procedure is generic, the exact content of the MAP and DTAP messages used to 
convey measurement and O&M commands and responses can vary between different position methods. The permanence 
of the SDCCH connection to the LMU is determined as follows: 



For an LCS information request from the SMLC to the LMU, the SMLC indicates if the LMU must retain the SDCCH. 
If this indication is provided, the LMU shall not initiate release of the current SDCCH after the LCS information request 
has been transferred. If the indication is not provided, the LMU may initiate release if the SDCCH is not needed at this 
time by the LMU. 
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For an LCS information response from the LMU to the SMLC, the LMU shall release or not release the current SDCCH 
after the message has been transferred according to the absence or presence, respectively, of the "Release Forbidden" 
indicator in the last LCS information request received from the SMLC. If there was no previous LCS information 
request (e.g. the LMU was recently powered on), the LMU shall assume permission to release. 

Following handover of an SDCCH to a new serving BTS, an LMU may instigate release of the SDCCH, even when the 
SMLC forbade SDCCH release, if the handover condition persists with the new BTS for more than a certain time 
interval. 
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1. MAP LCS Information Request 



7. MAP LCS Information Report 



BSC 
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6. DTAP LCS Inf jrmation Report 



LMU 



rmation Request 



Figure 15: Information Transfer Procedure for a Circuit Mode LMU 



The SMLC sends a MAP LCS Information Request to the MSC serving a particular LMU defining which location 
measurements or O&M actions should be started or stopped in the LMU and providing any data needed by the LMU to 
achieve this. Data related to periodic measurements or O&M actions (e.g. frequency, duration and filtering) may also be 
included. If this data exceeds the size of a single MAP message, further MAP LCS Information Request messages may 
be sent. The IMSI or LMSI identity of the LMU shall be conveyed in the LCS Information Request. In addition, the 
SMLC may indicate in the last LCS Information Request message that the LMU shall not release the SDCCH. 

If there is no SDCCH and mobility management connection to the LMU (e.g. LMU uses a temporary SDCCH), the 
serving MSC performs paging, authentication and ciphering to assign an SDCCH and establish a MM connection. 

The serving MSC passes the location instructions and data received from the SMLC to the LMU in either one DTAP 
LCS Information Request message for each received MAP LCS Information message. The last DTAP LCS Information 
Request shall indicate that the LMU shall not release the SDCCH if this was indicated by the SMLC. Once all the data is 
received, the LMU may initiate release of the CM and MM connections and the SDCCH, according to the procedures in 
GSM 04.71, if the information response in step 6 is not needed immediately and if the information response in step 6 is 
not needed immediately and the SMLC did not forbid release of the SDCCH. 

When the LMU has location measurement or O&M data to report and does not currently have an SDCCH and MM 
connection to the serving MSC, it requests an SDCCH and sends a DTAP CM Service request to the serving MSC to 
request an MM connection for location services. 

In response to any CM Service Request, the serving MSC performs authentication and ciphering for the LMU. 

The LMU sends a DTAP LCS Information Report to the serving MSC containing its location measurement or O&M 
results. If necessary, more than one of these messages may be sent to transfer a large quantity of data. Each Information 
Report may indicate the identity of the associated SMLC. The LMU may then release the MM connection to the MSC 
and the SDCCH if the SMLC did not forbid release of the SDCCH in step 3. 

The serving MSC forwards the contents of each separate Information Report to the SMLC with which the LMU is 
registered in a MAP LCS Information Report. This message shall also include the IMSI of the sending LMU. 
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6.9.5 SMLC Report Error Procedure 

The SMLC report error procedure may be optionally requested by an SMLC when attempting to transfer LCS 
Information to a particular LMU via its serving MSC. If the procedure is requested and the serving MSC cannot transfer 
LCS Information to the specified LMU, an LCS error indication is returned to the SMLC together with the content of 
the original LCS Information Request sent earlier by the SMLC. 



SMLC 



VMSC 



1. MAP LCS Information Request 



3. MAP LCS Information Report 



BSC 



LMU Paging Auths ntication, Ciphering 



LMU 



Figure 16 Report Error Procedure for a Circuit Mode LMU 



The SMLC sends a MAP LCS Information Request to the MSC serving a particular LMU defining which location 
measurements or O&M actions should be started or stopped in the LMU and providing any data needed by the LMU to 
achieve this. This message includes the IMSI and possibly LMSI identification of the target LMU and may include a 
report error indication. 

If the LMU is unknown to the serving MSC and a report error indication was included in step 1, the serving MSC shall 
return a MAP LCS Information Report message to the SMLC. This message shall contain the IMSI of the intended 
LMU, the location measurements or O&M data received in step 1 and the error cause. The SMLC may use the contents 
of the location or O&M data returned to correlate the Information Report with the specific LCS Information request sent 
earlier. Otherwise, if the LMU is known to the serving MSC but there is no SDCCH and mobility management 
connection to the LMU (e.g. LMU uses a temporary SDCCH), the serving MSC performs paging, authentication and 
ciphering to assign an SDCCH and establish a MM connection. 

If paging, or authentication is unsuccessful or if the LCS information cannot be transferred for some other reason, and 
the SMLC has requested an error report, the serving MSC shall return a MAP LCS Information Report message to the 
SMLC with the contents described in step 2. If paging and authentication are successful, the MSC transfers the location 
measurement or O&M data to the LMU as described in section 6.8.4. 



6.9.6 SMLC Data Restoration Procedure 

The SMLC data restoration procedure enables restoration of the registration status of one or more LMUs in an SMLC 
following either memory loss or data inconsistency in the SMLC. The procedure may be directed to either a particular 
identified LMU, a specific set of LMUs or to all LMUs served by an MSC that are registered with the SMLC. 
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Figure 17: SMLC Data Restoration Procedure 
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An SMLC sends a MAP LCS Reset message to a particular VLR. The message carries the identity of the SMLC and 
may carry the identities for a set of LMUs sharing this SMLC. If no LMU identities are indicated, steps 2 to 8 apply to 
each LMU served by the MVLRSC that is registered with the SMLC. If one or more LMUs are indicated, steps 2 to 8 
apply only to those LMUs identified by the SMLC that are served by the VLR and registered in the SMLC. 

For any LMU identified in step 1, the VLR shall reset the "location information confirmed in SMLC" indicator to "not 
confirmed". If the LMU currently has a LCS CM connection established to the serving MSC, the MSC shall send a 
DTAP LCS Release Complete to the LMU to release the LCS CM and MM connection. The cause in the Release 
Complete shall indicate "not registered in SMLC". 

If the MSC sends an LCS Release Complete in step 2 and there are no other (non-LCS) CM and MM connections 
between the MSC and LMU, the MSC may instigate release of the RR connection (e.g. SDCCH) by sending a DTAP 
Channel Release to the LMU. 

The LMU may later request the establishment of a LCS MM connection (e.g. if there was no connection to release in 
steps 2 and 3) by sending a DTAP CM Service Request to the MSC indicating a request for LCS. 

The MSC shall respond to any CM Service Request for LCS by returning a DTAP CM Service Reject with a cause of 
"not registered in SMLC". 

In response to either the release in steps 2 and 3 or the CM Service Reject in step 5, the LMU shall instigate the location 
registration and LCS Registration procedure described in section 6.8.2 (LMU registration). In response to a successful 
LCS registration, the SMLC may reset the LMU as described in section 6.8.7. 

Reset Procedure 



SMLC 



MSC/VLR 




BSC 




LMU 



1. MAP LCS Information Request (reset) 



5. MAP LCS Information Report (reset ack.) 



2. LMU paging, aufhe: itication, ciphering 



3. DTAP LCS Informa ion Request (reset) 



4. DTAP LCS Informati >n Report (reset ack.) 



Figure 18: Reset Procedure for a Circuit Mode LMU 



The SMLC sends a MAP LCS Information Request message to the MSC currently serving the LMU. This message 
carries the IMSI of the LMU and indicates if the LMU shall not release the SDCCH. The message also carries a LCS 
O&M reset operation. 

If the LMU is known to the MSC but currently has no SDCCH and mobility management connection, the serving MSC 
performs paging, authentication and ciphering to assign an SDCCH and establish a MM connection. If there is no 
response to paging or the LMU was unknown to the MSC, the LCS Information Request is discarded. In that case, the 
SMLC may timeout on the expected reply and infer that the LMU is unreachable. 

Assuming the LMU is reachable and an SDCCH was established, the MSC sends a DTAP LCS Information Request to 
the LMU carrying the LCS O&M reset. This message carries an "Release Forbidden" indicator if this was received in 
step 1. 

The LMU cancels all LCS measurement and O&M tasks previously ordered by the SMLC. The LMU then returns a 
DTAP LCS Information Report carrying a LCS O&M reset acknowledge. The LMU may then initiate release of the 
current SDCCH if the SMLC did not forbid this. 

The MSC forwards the reset acknowledge received from the LMU to the SMLC inside a MAP LCS Information Report. 
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6.9.7 Status Query Procedure 

The Status Query procedure enables an SMLC to verify the status of an associated LMU. The procedure may be 
instigated periodically or following any loss of communication with the LMU. 



SMLC 



MSC/VLR 



1. MAP LCS Information Request (status) 



5. MAP LCS Information Report (status ack.) 
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Figure 19: Status Query Procedure for a Circuit Mode LMU 



The SMLC sends a MAP LCS Information Request message to the MSC currently serving the LMU. This message 
carries the IMSI of the LMU and indicates if the LMU shall not release the SDCCH. The message also carries a LCS 
O&M status query. The message may also carry a "report error" indication to insure a response even when the serving 
MSC cannot forward the status query to the LMU (see section on Report Error procedure). 

If the LMU is known to the MSC but currently has no SDCCH and mobility management connection, the serving MSC 
performs paging, authentication and ciphering to assign an SDCCH and establish a MM connection. If there is no 
response to paging or the LMU was unknown to the MSC, the LCS Information Request is discarded. In that case, the 
SMLC may timeout on the expected status reply and infer that the LMU is unreachable. 

Assuming the LMU is reachable and an SDCCH was established, the MSC sends a DTAP LCS Information Request to 
the LMU carrying the LCS O&M status query. This message carries an "Release Forbidden" indicator if this was 
received in step 1 . 

The LMU returns a DTAP LCS Information Report carrying a LCS O&M status response. This LCS O&M response 
indicates the number of active measurement jobs and number of active O&M jobs in the LMU that were previously 
ordered by the SMLC. The LMU may then initiate release of the current SDCCH if the SMLC did not forbid this. 

The MSC forwards the status response received from the LMU to the SMLC inside a MAP LCS Information Report. 



6.10 Radio Interface Timing Procedures 

The Radio Interface Timing determination system consists of functions in LMUs and in the SMLC. The system runs 
continuously offering base station synchronization information for mobile station location. 



6.10.1 LMU Functions 

The Radio Interface Timing functionality in the LMU must be capable of performing the following functions: 



The LMU performs necessary air interface measurements from signals transmitted by base stations (both serving and 
neighbor). These signals can be normal bursts, dummy bursts, and synchronization bursts on the BCCH frequency. 



If the LMU contains the common reference clock, it time stamps reception of BTS signals. 



If there is no reference clock available, the LMU makes Real Time Difference measurements, i.e. measures the time 
difference between arrival of bursts from two base stations (e.g. serving and one of neighbors) 



The LMU performs some processing of measurements, like averaging and filtering, using parameters delivered to it, or 
in their absence using default settings. 
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6.10.2 SMLC Functions 

The SMLC must be capable of performing the following functions related to Radio Interface Timing determination: 
The SMLC sends to LMUs requests for Radio Interface Timing measurement information. 

The SMLC will communicate continuously with LMUs; thus, the SMLC can monitor operation of LMUs. If a LMU 
fails to send Radio Interface Timing information, the SMLC shall try to restart the LMU, and if this restarting fails, the 
SMLC shall inform O&M system. SMLC can use also diagnostics messages to query the status of LMUs. 

The SMLC receives Radio Interface Timing measurement results from LMUs. 

The SMLC stores or queries extra information required for base station synchronization determination, like base station 
and LMU coordinates, base station identity information (LAC, CI, BSIC, carrier), and burst length schemes. 

The SMLC determines synchronization differences between base stations using measurements and other information. 

Synchronization information is delivered for mobile station location purposes. 

6.10.3 LMU-SMLC Interactions 

The request for Radio Interface Timing measurement information from the SMLC to a LMU contains the following 
parameters: 

Measurement type. This indicates whether the SMLC wants the LMU to perform Absolute Time Difference (ATD) or 
Real Time Difference (RTD) measurements. 

Measurement result reporting frequency. This indicates how often the LMU should send Radio Interface Timing 
measurement results. 

Measurement duration. This indicates how long the LMU should make measurements and report results. 
Instructions about filtering of raw measurement data. 

Instructions about base stations to be measured. The LMU unit can measure autonomously a certain number of most 
strongly received base stations. Another possibility is that the SMLC tells which base stations it should measure. 

If the LMU measures signals from BTSs from other time slots than or 4, it must be informed about the burst length 
scheme used by BTSs. 

The Radio Interface Timing measurement response from a LMU to the SMLC contains: 
Location Area Code and Cell Identity of the serving base station. 

If the LMU can perform ATD measurements, and it is told to do them, the ATD measurement of the serving BTS is 
reported (i.e. time stamp for the reception of the burst from the serving BTS referred to the common reference clock). 

Time slot number of the burst(s) measured from the serving BTS. 

Frame number of the (last) burst measured from the serving BTS. 

For each measured neighbor BTS its identity as Location Area Code and Cell Identity or BSIC & carrier. 

For each measured neighbor BTS the possible ATD measurement is reported. This can be expressed relative to the ATD 
value of the serving BTS. 

If the LMU does not perform ATD measurements, for each measured neighbor BTS, Observed Time Difference value 
between the receptions of signals from the serving and the neighbor BTS is reported. 

For each measured neighbor BTS the time slot number of its burst(s). 

For each measured neighbor BTS the (last) frame number of its burst. 
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For each measured BTS the quality of measurements. Also the RX level can be reported. 



7 TA based Positioning 

7.1 Definition of TA states 

7.1.1 MS in IDLE State 

In IDLE state the GSM MS may be paged or may request an originating (e.g. emergency) call. The paging response 
message or CM Service Request, in each case respectively, received in COMPLETE_LAYER_3 message shall contain 
location information that includes the TA value. The TA value and other location information shall then be provided to 
the SMLC by the VMSC along with the current serving cell ID in the MAP Perform Location request (see section 6.4). 
This enables TA based positioning in the SMLC without any further interactions. 

7.1 .2 MS in DEDICATED State 

In DEDICATED state the SMLC shall send a TA_REQUEST to request the TA value from the serving BSC. The BSC 
shall respond with a TA_RESPONSE carrying the TA value. The associated procedure is described in section 7.2. 



7.2 TA Positioning Procedure for MS in Dedicated State 

The TA positioning procedure in dedicated state makes use of the generic SMLC to BSC Information transfer procedure 
defined in section 6.8.1. 
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Figure 20: TA Positioning Procedure for MS in Dedicated State 

The SMLC sends a MAP LCS Information Request to the visited MSC serving a particular target MS. The location 
information parameter in this message contains a TA Request. 

The VMSC transfers the TA Request received in step 1 to the serving BSC for the target MS inside a BSSMAP 
Location Command. 



The BSC returns the current TA value and current serving cell for the target MS to the VMSC in a TA response 
contained within a BSSMAP Location Report. The TA response also indicates whether a handover is currently ongoing 
for the target MS. 

The VMSC forwards the TA response received in step 3 to the SMLC inside a MAP LCS Information Report. The 
SMLC then derives a location estimate for the target MS based on the received serving cell ID and TA value. 
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8 



TOA based positioning 



8.1 Positioning Call Set-up, Positioning Call Deactivation and 
Positioning Functions 



The Positioning Call Set-Up and Positioning Call Deactivation functions are only meaningful at the NSS level and do 
not directly involve the BSS. 

Upon receiving a MAP Perform Location message from the VMSC, the SMLC will perform a positioning call set-up 
for an idle mobile prior to sending the MAP LCS Information Request message to BSS through VMSC. 

After receiving the 'BSSMAP Location Information Command' from VMSC, the BSC shall initiate procedures for 
position the MS with TOA positioning method. 
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8.2 TOA procedures 

8.2.1 Successful TOA Positioning Procedure 
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15. MESSAGES FOR RR CONNECTION RELEASE - REFER TO SECTION 8.2.1.2 



Figure 20: TOA measurement flows 



Positioning Preparations: 

SMLC, according to section 8.2.1 shall set up a positioning call before sending 'MAP Location Information Command' 
message for TOA positioning. If the MS is in dedicated mode, this step is skipped. 
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VMSC receives a 'MAP LCS Information Request' message from SMLC, which contains the BSC delta timer value and 
an indication of the preferred type of handover (intra-cell to same channel, intra-cell to new channel or inter-cell). The 
message also contains the cell ID and TDMA frame number of the serving cell, and depending on the preferred 
handover type, also contains the cell ID and TDMA frame number for candidate (maximum six) cells for positioning 
handover. 

The MSC sends the BSSMAP Location Information Command' message to BSC with the same information received in 
step 2. 

The BSC specifies the physical channel information (frequencies, hopping sequence, channel type, time slot for access 
burst etc.), cell ID, TA, measurement report, MS output power, and handover reference number in the 'BSSMAP 
Location Information Report' message to the VMSC. The BSC also starts the delta timer. 

Note: If the BSC selects to use a different channel, this channel is reserved internally within the BSC, i.e. no additional 
signaling or delay is required. Based on the request information from SMLC, the BSC can choose between requesting an 
intra-cell handover (to same channel or to a new channel) or an inter-cell handover. If BSC decides to make an inter-cell 
handover the BSC selects a neighbor cell based on the measurement reports received from the MS (only neighbors for 
which the MS has been able to decode BSIC are possible to specify since the MS needs to know the timing of the target 
base station). 

The VMSC forwards the information received from BSC (in 4) to the SMLC in 'MAP LCS Information Report' 
message. SMLC uses this information for the configuration of the LMUs. 

The SMLC selects which LMUs should measure and sends LCS Information Request messages for each of these LMUs 
to the MSC according to the procedure defined in section 6.9.4. Each LCS Information Request message is targeted to 
one LMU and specifies Radio Frequency List, Hopping Sequence Information, HO reference number, BSIC, Starting 
Time, Measurement Options, Starting Time Uncertainty, GPS Time Stamping Request. 

The MSC converts the MAP message from the SMLC into a DTAP message, which reaches the LMUs over the air 
interface. It has been assumed here that the DTAP connection is already established at this point (refer to section 6.9.4). 

Positioning Establishment: 

At expiration of the delta timer (note 1), the mobile is instructed to perform non-synchronized handover to a specified 
channel with HANDOVER COMMAND message. A TDMA frame number at which the sending of ACCESS burst 
should begin is specified. 

The MS starts sending the access burst in HANDOVER ACCESS message. At the same time, configured LMUs 
measure the Time of Arrival of access bursts. 

The MS continues to send the access bursts until the timer T3124 expires when the MS returns to the old channel. 
The MS sends the HANDOVER FAILURE message to the BSC. 

LMUs report their measurement results in a DTAP LCS Information Response message to the VMSC. 

The measurement results will be forwarded to the SMLC as a MAP LCS Information Response message with measured 
TO A, TOA quality estimate, and Used Time Stamping. SMLC shall keep track of the number of expected measurement 
results from LMUs in the network. 

If a location estimate satisfying the requested QoS was not successfully obtained, the SMLC may initiate another TOA 
location attempt by restarting the TOA procedure at step 1. Otherwise, the SMLC will send an acknowledgement to the 
initial Location Request from the MSC containing the location estimate of the mobile station being positioned. 

The returned location result from the SMLC shall trigger the MSC to start the RR Connection Release process if the MS 
was initially idle (see 8.2.1.2). 

NOTE 1: BSC starts the delta timer when received from the MSC in (2). The purpose of this timer is to allow 
enough time for MLC to initialize and configure all the LMUs for the TOA measurement. This timer 
value should be long enough for this task. When the BSC timer runs out, the BSC starts the handover 
process (step 10). 



ETSI 



(GSM 03.71 version 7.0.0 Release 1998) 



49 



ETSI TS 101 724 V7.0.0 (1999-08) 



NOTE 2: After a traffic channel is allocated to the MS to be positioned, the MS starts sending measurement reports 
to the serving BTS. Based on these measurement reports the BSC would normally order handovers when 
considered necessary. If a radio related handover would take place between message 2 and 9, this would 
invalidate the information sent to the LMUs and positioning would fail. After the initialization of the delta 
timer in the BSC (step 5), the BSC shall cancel the ongoing positioning if a radio related handover has 
been requested. On the other hand, the BSC shall never allow any radio-related handover during steps 10 
and 13 (Is it 13 or 16?). 

8.2.1 .1 Positioning call set-up 
8.2.1.1.1 Normal Case 



SMLC 



VMSC 



BSC 



1 . MAP Assign Traffic Channel 



2. Assignment Request 



8. MAP Assign Traffic Channel Ack 



BTS 



3. Channel Activation 



4. Channel Activation Ack 



5. Assignment Command 



65 Establish Indication 



7. Assignmei 



MS 



t Complete 



Figure 21 : TOA positioning call set-up for normal case 

SMLC sends 'MAP Assign Traffic Channel' message to VMSC for an MS not allocated with a traffic channel. 
VMSC sends an ASSIGNMENT REQUEST message to BSC, for the set-up of a traffic channel. 
The activation of the BTS is ordered by the BSC with CHANNEL ACTIVATION message. 

The BTS acknowledges the allocation of the speech channel by sending CHANNEL ACTIVATION ACKNOWLEDGE 

message. 

The BSC then sends an ASSIGNMENT COMMAND message towards the MS, telling the mobile station to switch to 
the new channel. 

When the MS has switched to the new channel, the ESTABLISH INDICATION message is sent from the BTS. 

The MS then sends the ASSIGNMENT COMPLETE message to the VMSC indicating that the traffic channel is up and 
running. 

VMSC sends 'MAP Assign Traffic Channel Ack' message to SMLC. 



8.2.1.1.2 Directed Retry 

If radio related conditions require the assignment of a new serving cell during a positioning call setup, the directed retry 
handover procedure defined in GSM 03.09 shall be used instead of the normal procedure described previously to assign 
a traffic channel. The VMSC shall then indicate a failure of the ordered TOA procedure to the SMLC and include within 
the failure indication the reason for failure (directed retry) and the identity of the new serving cell. The SMLC may then 
order a new TOA location attempt based on the new cell. 
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8.2.1 .2 RR Connection Release for TOA Positioning for an Idle MS 

Once the positioning process has completed for an idle MS, the MS must go back to idle mode and the resources must 
be released. The method for releasing of RR connections is the same as in current GSM standard. 

9 Position calculation functionality 

9.1 TA 

For the TA once the cell-ID and TA value has been returned to the MLC, the MLC PCF should map this information 
into a standardized format suitable for the client. This may infer either just passing the received information in its 
current format or representing the area in some manner. 

9.2 Time Of Arrival (TOA) Positioning 

For the TOA positioning mechanism once the cell-IDs, TOA values and TOA measurement quality information has 
been returned to the MLC, the MLC PCF should estimate the position of the MS based on this information and MLC 
prior knowledge of RTDs and BTS co-ordinates. The estimated MS position is then mapped and/or converted into a 
standardized format suitable for the requesting client. 



10 Information storage 

This section describes information storage structures that are mandatory (M), conditional (C) or optional (O) for LCS, 
and the recovery and restoration procedures needed to maintain service if inconsistencies in databases occur and for lost 
or invalid database information. 

10.1 HLR 

The HLR holds LCS data for both MS subscribers and LMUs. 

10.1.1 LCS Data in the HLR for an MS Subscriber 

The IMSI is the primary key for LCS MS subscription data in the HLR. This subscription data may be stored in a 
Multiple Subscriber Profile (MSP), with the HLR able to hold a number of MSPs per IMSI. 

LCS MS subscription data includes a privacy exception list containing the privacy classes for which location of the 
target MS is permitted. Each privacy class is treated as a distinct supplementary service with its own supplementary 
service code. The following logical states are applicable to each privacy class (refer to GSM 03.1 1 for an explanation of 
the notation): 



Table 2: Logical States for each LCS Privacy Class 



Provisioning State 


Registration State 


Activation State 


HLR Induction State 


(Not Provisioned, 


Not Applicable, 


Not Active, 


Not Induced) 


(Provisioned, 


Not Applicable, 


Active and Operative, 


Not Induced) 



For each LCS privacy class, the HLR shall store the logical state of the class on a per-subscriber (or per subscriber 
MSP) basis. In addition, the permanent data indicated below shall be stored on a per subscriber (or per subscriber MSP) 
basis when the logical provisioning state of the associated LCS privacy class is "provisioned". For the meaning of each 
LCS privacy class, refer to section 6.6 and to GSM 02.71. 
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Table 3: LCS data stored in the HLR privacy exception list for an MS Subscriber 

(or MS Subscriber MSP) 



LCS Privacy Class 


Status 


Additional HLR Data when Class is provisioned 


Universal Class 




No additional data 


Call Related Class 




No additional data 


Call Unrelated Class 


o 
c 

c 


External LCS client list: a list of one or more LCS clients, with the 

following data stored for each LCS client in the list: 

International E.164 address identifying a single LCS client or a single 

group of LCS clients that are permitted to locate this target MS 

Restriction on the GPLMN (PLMN containing the GMLC). Possible 

values are: 

HPLMN only 

Any PLMN in the home country 
Any PLMN (no restriction) 


PLMN Class 


o 


LCS client list: a list of one or more generic classes of LCS client that 
are allowed to locate the particular MS. The following classes are 
distinguished: 

LCS client broadcasting location related information 

O&M LCS client in the HPLMN 

O&M LCS client in the VPLMN 

LCS client recording anonymous location information 


Self Location Class 




No additional data 



In addition to the privacy exception list, the following other data items may be stored in the MS subscription profile in 
the HLR to support LCS: 



Table 4: Temporary LCS data in the HLR 



Other Data in the HLR 


Status 


Description 


Home GMLC List 


o 


List of one or more E.164 addresses of the GMLCs in the home PLMN 
from which a location request for an MT-LR is allowed, The addresses 
are only relevant to an LCS client that is restricted (in the MS privacy 
exception list) to making call unrelated location requests from the home 
PLMN. 



10.1.2 LCS data in the HLR for an LMU 

The IMSI is the primary key to LMU data stored in the HLR. Any subscription data that is applicable to an MS 
subscriber may be held by the HLR for an LMU, since the LMU is treated by the HLR similarly to an MS subscriber. 
However, a HLR will normally restrict LMU subscription data to just the IMSI, MSISDN, SMS-PP MT (if assigned) 
and barring of all incoming and possibly outgoing calls. Use of MSPs is also unnecessary for an LMU. 

An HLR also needs to hold the following additional permanent data for an LMU. 



Table 5: Additional permanent data in the HLR for an LMU 



Additional LMU Data in HLR 


Status 


Description 


LMU Indicator 


M 


Distinguishes an LMU from a normal MS Subscriber 



10.2 VLR 

The VLR contains the same LCS permanent data for each registered MS subscriber and each LMU, as does the HLR. 
This data is downloaded to the VLR as part of the location update procedure between the VLR and HLR for either an 
MS subscriber or LMU. 

The VLR contains the following temporary data for any LMU 
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Table 6: Temporary data in the VLR 



Temporary VLR Data Item 


Status 


Description 


Location Information Confirmed in 
SMLC 


M 


Indication of whether the LMU was successfully registered in 

an associated SMLC with possible values 

Confirmed (registered) 

Not Confirmed (not registered) 


SMLC address 


C 


Identity of the SMLC in which the LMU is registered 
either international E.164 address 
or SS7 signaling point code 



10.3 GMLC 

The GMLC holds data for a set of external LCS clients that may make call related or non-call related MT-LR requests to 
this GMLC. The permanent data administered for each LCS client is as follows. 



Table 7: GMLC Permanent Data for a LCS Client 



LCS Client data in GMLC 


Status 


Description 


External identity 


M 


A list of one or more identifiers used to identify an external LCS client 
when making an MT-LR - the nature and content of the identifier(s) is 
outside the scope of the present document 


Authentication data 


M 


Data employed to authenticate the identity of an LCS client - details are 
outside the scope of the present document 


Call related identity 


O 


A list of one or more international E.164 addresses to identify the client 
for a call related MT-LR 

Each call related identity may be associated with a specific external 
identity 


Non-call related identity 


O 


A list of one ore more international E.164 addresses to identify the client 
for a non-call related MT-LR. 

Each non-call related identity may be associated with a specific external 
identity 


Override capability 


o 


Indication of whether the LCS client possesses the override capability 


Authorized MS List 





A list of MSISDNs or groups of MSISDN for which the LCS client may 
issue a non-call related MT-LR. Separate lists of MSISDNs and groups of 
MSISDN may be associated with each distinct external or non-call related 
client identity. 


Priority 


M 


The priority of the LCS client - to be treated as either the default priority 
when priority is not negotiated between the LCS server and client or the 
highest allowed priority when priority is negotiated 


QoS parameters 


M 


The default QoS requirements for the LCS client, comprising: 

Accuracy 

Response time 

Separate default QoS parameters may be maintained for each distinct 
LCS client identity (external, non-call related, call related) 


Allowed LCS Request Types 


M 


Indicates if the following are allowed: 

Non-call related MT-LR 

Call related MT-LR 

Specification or negotiation of priority 

Specification or negotiation of QoS parameters 


Local Coordinate System 


O 


Definition of the coordinate system(s) in which a location estimate shall 
be provided - details are outside the scope of the present document 


Access Barring List(s) 


O 


List(s) of MSISDNs or groups of MSISDN for which a location request is 
barred 
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10.4 SMLC 
10.4.1 Common Data 

The following table holds permanent BTS data: 



Table 8: Permanent SMLC Data for a BTS 



Permanent BTS Data Item 


Status 


Description 


BTS position 


M 


BTS position (latitude/longitude) of the Serving BTS 


CGI 


M 


Cell global identity. 


BSIC 


M 


Base station identity code. 


BCCH 


M 


Frequency of the broadcast carrier. 



The SMLC holds data for its associated LMUs. The main key to LMU data in the SMLC is the IMSI of the LMU. LMU 
data provides the location capabilities of the LMU (e.g. which location and assistance measurements are supported). The 
following permanent data shall be administered for any LMU: 



Table 9: Permanent SMLC Data for an LMU 



Permanent LMU Data Item 


Status 


Description 


IMSI 


M 


Main key to LMU data 


Serving Cell 


M 


Identity of the cell in which the LMU is physically located 


Geographic location 


C 


Latitude/longitude coordinates 

Storage of coordinates is mandatory for TOA if an LMU is not co-located 
with a BTS 


Position measurement 
functions 


O 


List of supported position measurements 

For each type of position measurement, a list of associated capabilities - 
details are outside the scope of the present document 


Assistance measurement 
functions 


O 


List of supported assistance measurements 

For each type of assistance measurement, a list of associated 

capabilities - details are outside the scope of the present document 


Diagnostic functions 


O 


List of supported diagnostic functions - details are outside the scope of 
the present document 



The SMLC also holds the following temporary data for each LMU, where data items other than the registration state are 
only valid when the registration state is "registered". 



Table 10: Temporary SMLC Data for an LMU 



Temporary LMU Data Item 


Status 


Description 


Registration State 


M 


Indication of whether the LMU has successfully registered 

with possible values: 

registered 

not registered or de-registered 


Serving MSC 


M 


Identity of the serving MSC 
either international E.164 address 
or SS7 signaling point code 


LMSI 


C 


LMSI in serving VLR if provided during registration 


Position Measurements 


O 


Ongoing and scheduled position measurements ordered in 
the LMU by the SMLC - details are outside the scope of the 
present document 


Assistance Measurements 


O 


Ongoing and scheduled assistance measurements ordered 
by the SMLC - details are outside the scope of the present 
document 


O&M Activities 


O 


Ongoing and scheduled O&M activities ordered in the LMU by 
the SMLC - details are outside the scope of the present 
document 



ETSI 



(GSM 03.71 version 7.0.0 Release 1998) 54 ETSI TS 101 724 V7.0.0 (1999-08) 

10.4.2 TOAData 

The following data are specific to TOA and shall be administered in the SMLC: 



Table 1 1 : Permanent SMLC Data for an LMU 



Permanent LMU Data Item 


Status 


Description 


Number of Measurement 
Devices (Note 1 ) 


M 


Number of measurement devices contained in the LMU. 


Number of Simultaneous 
Measurements (Note 2) 


M 


LMU total measurement capacity. 


Data items for each 
measurement device: 






Beamwidth 


M 


Azimuthal coverage in degrees for each LMU measurement device. 


Orientation 


M 


Main beam pointing angle counter-clockwise looking down with respect 
to North in degrees for each LMU measurement device. 


Gain 


O 


LMU measurement device antenna gain at foresight in dB. 


Number of Simultaneous 
Measurements 


o 


Maximum measurement capacity in a single LMU measurement device. 
(Assume dedicated receivers if this field is not specified.) 



NOTE 1: The term "measurement device" is used both to indicate the LMU sector and to avoid confusion with the 
BTS sectors when LMU sectors are not coincident with BTS sectors. 



NOTE 2: A "measurement" refers to the time interval required for an entire TOA measurement. If any portion of the 
interval overlaps, it is considered simultaneous. 

An LMU contains no mandatory data regarding its associated SMLC. An LMU shall contain permanent data regarding 
its measurement and O&M capabilities and may contain pre-administered data regarding location assistance 
measurements and O&M activities that the LMU is to perform without the need for any command from the SMLC. The 
content of such location measurement and O&M related data is outside the scope of the present document. 

10.5 Recovery and Restoration Procedures 

The LCS recovery and restoration procedures allow temporary data to be recovered or reinitialized following loss or 
corruption of data, such that normal LCS service is rapidly restored and inconsistency between the data held by different 
LCS network elements is removed. For a full description, refer to GSM 03.07. 



1 1 Operational Aspects 
11.1 Charging 

11.1.1 Charging Information collected by the PLMN serving the LCS Client 

The following charging information shall be collected by the PLMN serving the LCS Client: 
Identity of the LCS Client; 
Identity of the target MS; 

Results (e.g. success/failure, method used if known, response time, accuracy) - to be repeated for each instance of 
positioning for a deferred location request; 

Identity of the visited PLMN; 

LCS request type (i.e. LDR or LIR); 

State; 

Event (applicable to LDR requests only); 



ETSI 



(GSM 03.71 version 7.0.0 Release 1998) 55 ETSI TS 101 724 V7.0.0 (1999-08) 

Time Stamp; 

Type of coordinate system used. 

11 .1 .2 Charging Information Collected by the Visited PLMN 

The following charging information shall be collected by the visited PLMN: 
Date and time; 
Identity of the target MS; 

Location of the target MS (e.g., MSC, location area ID, cell ID, location coordinates); 
Which location services were requested; 

Results (e.g. success/failure, positioning method used, response time, accuracy) - to be repeated for each instance of 
positioning for a batch location request; 

Identity of the PLMN serving the LCS Client; 

State; 

Event (applicable to LDR requests only); 
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Annex A (informative): 
Examples of MT-LR 

This Annex provides examples of both call related and non-call related mobile terminated location request from an 
external application, where multiple PLMNs are involved. 



A.1 PLMN Roles 



A PLMN can have one or more of the following roles in supporting the LCS service. 



Gateway PLMN (GPLMN) 


The PLMN in which a location request originates. For an MT-LR, the 
GPLMN contains the GMLC. 


Home PLMN (HPLMN) 


The home PLMN for the MS being located. The HPLMN contains the HLR 
for the located MS. 


Visited PLMN (VPLMN) 


The PLMN currently serving the MS being located. The VPLMN contains 
the MSC/VLR serving the located MS, the SMLC and any LMUs used to 
perform the location. 



A.2 Non-Call Related MT-LR 




Figure 1 : Non-Call Related MT-LR 

1 . A external Location Application (LA) sends a Location Request to a GMLC in its serving GPLMN requesting the 
location of a particular MS. 

2. The GMLC queries the HLR of the MS to be located by sending a MAP query to the HPLMN of this MS. In order 
to route the query to the HLR, translation of the MSISDN of the MS to be located will be required. This translation 
may be performed within the GMLC and/or may be performed by intermediate STPs. 
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3. The HLR returns the E. 164 address of the VMSC currently serving the MS in the VPLMN. 

4. The GMLC forwards the location request to the VMSC and includes within it the identity of the LA. In order to 
route the request to the VMSC, translation of the E.164 address of the VMSC will be required. This translation may 
be performed within the GMLC and/or may be performed by intermediate STPs. 

5. The VMSC verifies that the MS allows a non-call relkated MT-LR in its privacy exception list and that the LA 
identity provided by the GMLC matches an LA identity in the MS privacy exception list. The VMSC then interacts 
with an SMLC and possibly one or more LMUs in the VPLMN to perform positioning of the MS. 

6. The resulting location estimate is returned by the VMSC to the GMLC. The VMSC uses the E.164 address or SS7 
signaling point code of the GMLC, provided in step 4, to correctly route the location estimate to the GMLC in the 
GPLMN. 

7. The GMLC returns the location estimate to the requesting LA. 



A.3 Call Related MT-LR 




Figure 2: Call Related MT-LR 

1. An MS requests a voice or data call to some external Location Application (LA). 

2. The call is routed from the VMSC through the PSTN to the LA. The MSC stores the original dialed number and the 
PSTN or PSPDN number that was used to route the call if different. 

3. The external LA obtains the MSISDN of the calling MS - either verbally or using calling line ID presentation. The 
LA may also need to verify the number dialed by the MS - e.g. if the LA can be reached by any of several dialed 
numbers. The external LA sends a Location Request to a GMLC in its serving GPLMN requesting the location of 
the MS and providing both the MSISDN and its own PSTN PSPDN number as used by the MS. 

4. The GMLC queries the HLR of the MS to be located by sending a MAP query to the HPLMN of this MS. In order 
to route the query to the HLR, translation of the MSISDN of the MS to be located will be required. This translation 
may be performed within the GMLC and/or may be performed by intermediate STPs. 

5. The HLR returns the E. 164 address of the VMSC currently serving the MS in the VPLMN. 
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6. The GMLC forwards the location request to the VMSC and includes within it the PSTN or PSPDN number of the 
LA. In order to route the request to the VMSC, translation of the E.164 address of the VMSC will be required. This 
translation may be performed within the GMLC and/or may be performed by intermediate STPs. 

7. The VMSC verifies that the MS allows a call related MT-LR in its privacy exception list, that it currently has an 
originated call established and that the PSTN or PSPDN number supplied by the GMLC matches the number either 
dialed by the MS or used to route the call. The VMSC then interacts with an SMLC and possibly one or more 
LMUs in the VPLMN to perform positioning of the MS. 

8. The resulting location estimate is returned by the VMSC to the GMLC. The VMSC uses the E.164 address or SS7 
signaling point code of the GMLC, provided in step 4, to correctly route the location estimate to the GMLC in the 
GPLMN. 

9. The GMLC returns the location estimate to the requesting LA. 
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